home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Mar 90 / MacApp.Tech$ 3⁄2⁄90 / 0767-Combined purge and d-Feb90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.8 KB  |  113 lines  |  [TEXT/GEOL]

  1. Item    8685373                         25-Feb-90        14:11PST
  2.  
  3. From:   GER.XDV0002                     Germany - P1 Ges f Informatik,IVR
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Combined purge and dehydrate!
  8.  
  9. I am following the "persistent" discussion with great interest via the weekly
  10. summaries. I am not a member of MACAPP.TECH$ (too much incoming mail) and
  11. therefore the following proposal may be already a little bit out of date.
  12.  
  13. During reading Greg's paper "persistence (longish)" I had the following idea:
  14.  
  15. I think we can handle "purged" objects nearly as "dehydrated" objects and
  16. combine both advantages!
  17.  
  18. The compiler does not need a valid object handle to call a method! The first
  19. dereferencing of an object handle is only done either in the method dispatch
  20. routine (polymorphic methods) or inside the called method (optimized
  21. monomorphic methods).
  22.  
  23. The method dispatch routine can be patched to test for an odd handle (used as
  24. indication that the handle is no handle but an object ID) and call a routine
  25. which delivers the needed class ID for purged objects. This routine should also
  26. read in the object and replace the object ID by the object handle.
  27.  
  28. The first call inside the method must be "Lock (SELF)" if objects of this class
  29. may be dehydrated or purged. Lock has to test for the three possible states of
  30. an object:
  31. 1) loaded:
  32.     SELF is the normal object handle:
  33.     Nothing to do.
  34. 2) dehydrated:
  35.     SELF is a valid handle, but points only to the dehydrated information:
  36.     The object must be read in by using the dehydration info.
  37. 3) purged:
  38.     SELF is an object ID (e.g. indicated by an odd value):
  39.     The object cache must be used to read in the object and SELF must be
  40.     replaced by an object handle value. As SELF cannot be passed as a VAR
  41.     parameter to Lock we need some knowledge of the generated code of the
  42.     compiler (note the generic name, there are others than Object Pascal and
  43.     I am not thinking at C++!) but this is easy because the implicit SELF
  44.     parameter has always the same frame offset ("8(A6)" in Object Pascal and
  45.     Modula-2).
  46.  
  47. A similar classification will apply to classes:
  48. 1) standard:
  49.     All objects are always loaded.
  50. 2) dehydratable:
  51.     Objects may be dehydrated but not purged:
  52.     All methods must have a call to Lock as first statement.
  53. 3) purgable:
  54.     Objects may be dehydrated or purged:
  55.     All methods must have a call to Lock as first statement and all
  56.     references to objects of these classes must use object IDs.
  57. For both dehydratable and purgable classes references to object fields are only
  58. allowed after a call to Lock, but preferable they should be encapsulated in
  59. methods.
  60.  
  61. Lock can be even a parameterless method of TObject but overriding it must be
  62. done with care because the inherited call of Lock will only replace the object
  63. ID in the calling Lock method but not in the method which called Lock. To do
  64. this there would be needed a procedure (method?) "UpdateSELF" to replace the
  65. object ID by SELF in the method above (two stack frames above from inside
  66. UpdateSELF). These last ideas may be a little bit confusing and superfluous but
  67. they show the flexibility of such an approach.
  68.  
  69. Unlock should be a parameterless method of TObject with an empty
  70. implementation. By overriding Unlock you can then decide whether the object
  71. should be dehydrated or purged. Unlock must be called at the end of each method
  72. which calls Lock.
  73.  
  74. The overhead for this solution is very limited, for loaded objects of standard
  75. classes it is only one additional test in the method dispatch routine.
  76.  
  77.  
  78. Please send a copy of any direct comment to my AppleLink address (GER.XDV0002)
  79. then I have not to wait for the next TECH$ summary. Thank you.
  80.  
  81. Elmar Henne
  82. p1 GmbH, Munich
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.